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models which can be perturbed to evaluate the net and make 
recommendations or implement improvements to the software. 

4. Establish a support function, perhaps independent of the soft¬ 
ware developer, to establish and document the protocols. 
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c) Configuration Control 

The configuration control effort has been handled in a rather in¬ 
formal fashion with a great deal of autonomy and an indefinite di¬ 
vision of responsibilities among the organizations that address the 
various elements of this function. Personal contacts, telephone 
conversations, and understandings are relied upon for day to day 
operation. 

This environment is a natural outcome of the progressive R&D atmosphere 
that was necessary for the development and implementation of the 
network concept. It was appropriately adjudged that too much control 
would have lengthened the time frame of progress. The system is 
still relatively new and in a constant state of flux but the 
essential task of setting up an interactive resource sharing net¬ 
work has been accomplished. As the ARPANET moves more and more 
toward becoming an operational utility all of the management 
activities need to be formalized and the policies and procedures 
made definite. 

The network does not really exist as an entity now but rather as a 
group of cooperative but essentially autonomous computer systems. 

There is a whole set of activities which can't proceed until it 
evolves into such a total system. The sophisticated utilization 
of multiple computers for a single application depends upon having 
the individual services at a sufficiently reliable and accessible 
level. This in turn cannot be effected without direction, accurate 
documentation and active exercise of control. 

RECOMMENDATIONS 

Current practices have led to a scarcity of accurate documentation. 

The NIC directed effort has not been sufficient due to its passive 
nature. Responses to questionnaires and voluntary submittal of in¬ 
formation have been sparse. A more active documentation effort 
should be undertaken. Host sites may not have the time or sufficient 
interest or manpower to generate complete documentation and a 
separate organization to aid them in this function is required. 

Current methods are too informal and inefficient from an operations 
standpoint. 

Consideration should be given to directing the network analysis 
effort and coordinating the various organizations involved. No 
quantitative use is currently made of the data taken by BBN or the 
NMC. The NAC studies are completely divorced from operational con¬ 
siderations and no effort has been made to verify the assumptions 
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made in their analyses. With the NAC software available on-line, 
as is projected, an evaluation and integration of the various 
analytic efforts directed toward characterizing system performance 
seems a natural and advantageous undertaking. 

As the network expands it will become necessary to evaluate more 
closely the roles of both servers and users, and their inter¬ 
relationships. A healthy mix of resources and customers must be 
maintained in order to insure high utilization levels and sufficient 
processing capacity. 



4) (cont) 


d) Network Equipment and Communication Channels Reliability, 
Availability and Capacity 

As the network grows and achieves a greater operational identity the 
need for a systems effectiveness effort will become more pronounced. 
The existance of the elements and considerations necessary to es¬ 
tablish system effectiveness are available however, there does not 
appear to be any coordinated effort towards this end at the present 
time. 

The advertised error rate of the network is 1 in 10^ or approximately 
one undetected bit error per year. Such a small probabilistic fac¬ 
tor cannot be realistically measured nor would there be any reason 
for it if there is confidence in the design implementation. The 
number of retransmissions that occur, however, is noted by the NCC 
and this data should be reviewed and analyzed constantly and closely 
in order to identify and correct recurring and hidden causes for 
retransmission. 

The current reliability of the IMP/TIP hardware is 98% and is not 
acceptable primarily, because there is no redundancy in this area 
and when its IMP/TIP is down the Host is down and connectivity is 
impaired. The desired reliability figure is 99.9%. To attain that 
may require redundant hardware, however prior to this costly under¬ 
taking it is highly advisable that an in depth analysis of the 
failures be completed to identify and if possible correct the actual 
causes of failures. Some of the necessary information is already 
available at the NCC but is more qualitative than definitive in 
this regard. Another area to be addressed is the non-availability 
categories of the IMPs/TIPs. In this respect possibly the only 
changes necessary to improve reliability would be in procedures. 

The operating structure of the network and status reporting system 
lends itself readily to complete automation of determining, storing 
and presenting the referenced reliability parameters, given adequate 
off-line storage mediums. Some minimal programming at NCC would be 
required to categorize and store the run data for processing and 
presentation of reports. 

The capacity of the network under varying conditions is based on 
an average rate model, and requires certain general assumptions. 

NAC does not use any data from BBN or the NMC to verify or modify 
their analysis. NMC does perform measurements of network operation, 
but little has been done to characterize system performance. NMC 
realizes that their studies have not given sufficient attention to 
the perturbations caused by the measurements, or to the base ’level 
of overhead traffic. NMC has been hampered by an inability to 
generate high traffic levels, and would like to encourage high rate 
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Host traffic generators for measurement use. Systems capacity has 
not been measured due to these difficulties, however, except in 
special circumstances 50 kilobit per second circuits are used. The 
network overhead reduces this to effectively 45 kilobits. Data 
should be gathered to determine the effect packet retransmission 
has on this figure. 

NMC has made observations of real traffic moving from IMP to adjacent 
XMP, and has concluded that long multipacket messages show much 
better throughput for destinations many IMP hops away from their 
sources. Buffer allocation presently limits message length to 
eight packets. This maximum message size, packet size of approximately 
.1,000 bits were established somewhat empirically. Analysis effort 
is indicated to optimize packet considerations as data on network 
usage becomes available. 

Capacity presently assumes high peak to average traffic with the 
goal of interactive usage requiring an end-to-end delay of less than 
% second. This leads to line capacities greater than that necessary 
to support the average traffic of all the sites. As network utiliza¬ 
tion increases, at some point, capacity must also increase. Whether ■ 
some denigration of service should be sustained, for reasons of 
economy, is yet to be determined. Current traffic is well below 
capacity, and costs have only been estimated, so this question 
has not been addressed. 

Network studies have been conducted by several organizations and 
individuals predominantly on a theoretical level. NAC has de¬ 
veloped a rate model of the network. UCLA and BBN have simulation 
models. Graduate students at UCLA are working on analytic methods 
of generating network topologies. The NMC has done studies on 
point to point throughput, some cost relationships, and on buffer 
management. 

Much good work has been done but in a widely scattered and diverse 
manner. The various efforts should be coordinated and directed 
toward the common goal of characterizing the network as an entity. 

Much more verification of analytic techniques should be done through 
measurements on the network. The need for a coordinated, overall 
systems analysis effort will become increasingly apparent as the 
network emerges from the R&D phase. 

RECOMMENDATIONS 

It is recommended that a single agency be given the responsibility 
of establishing and implementing a total systems approach to the 
network. This effort should include establishment of an overall 
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4/d (cont) 

plsn, identifying the penticipating agencies, level of effort re¬ 
quired, goals to be attained, and trial time schedules. Actual 
time schedules would have to be established by the individual 
agencies involved, and once established would serve as a motivational 
tool, rather than a forcing device. 

The implementation of such an effort will require the ability to 
cross administrative, political, and corporate lines in a manner 
that will promote the cooperation and coordination necessarv to 
the success of a total systems effort. 
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4) (cont) 


e) Network Configuration Analysis 

A significant amount of valuable software has been developed by NAC 
for network configuration analysis of the ARPA net. This software 
has been refined to a point where it is quite effective. It has 
the capability of optimizing for both throughput and reliability 
versus cost. However, very little use of it has been made for 
optimizing reliability. The model in use is static, rather than a 
dynamic model, and does not make use of real data gathered on the 
network in determining topology. Neither has there been any efforts 
to validate the current model using actual data. 

RECOMMENDATIONS 

A central organization should be assigned the responsibility for 
accomplishing, at'least the following tasks; 

1. Gathering and inclusion of reliability data into the topological 
analysis. 

2. Collect and use real network data, to the greatest extent 
possible, in determining network configuration. 

3. Validate the topological models using data collected from the 
network. 
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4) (cont) 

f) Requirements for Special Technical Assistance 

The "Request for Comment" is the most widely used document for 
identifying problem areas requiring special effort. These would be 
directed to ARPA or BBN as may be appropriate. The Network Working 
Group, while not very active at this time, does serve as a means of 
identifying Host to Host protocol problem areas. 

Network facilitators are able to-provide some assistance on special 
interface requirements, and refer the new member to a more knowledge¬ 
able Host if possible. BBN may also be contacted in this regard. The 
new member can obtain some knowledge of network and Host level pro¬ 
tocols from the existing documentation. For special requirements or 
specific questions the customer is encouraged to contact other users 
as may be appropriate. Training assistance as such is not available. 
There is no effort to provide in depth services to a new user during 
his entry to the network. No consulting service, or other single source 
capable of providing complete network entry and initial operating in¬ 
struction has been found. 

The network measurement center at UCLA presently performs extensive 
statistics and trace gathering in connection with regular message 
flow and artifical traffic generation. Repeatability of these tests 
is questionable due to the problems associated with performing con¬ 
trolled tests within a continuously used and variable dimension oper¬ 
ating system. 

Statistical analysis and/or simulations are required to evaluate the 
routing algorithms, buffering technique, traffic distributions and 
other system parameters. Further assistance is required to develop 
a procedure which can be used for a higher level of IMP/TIP software 
verification. 

Optimization effort is limited at this time to the NAC topology 
endeavor. Optimization effort on the communications level is of 
prime importance in increasing cost effectiveness, and "fine tuning" 
of the network. Factors such as message lengths, packet size, and 
Host to Host protocol actualization, greatly affect system operation 
and could benefit from optimization studies. Optimum usage of the 
network has not been defined. A periodic report of various transfer 
rates etc., and how they were achieved would be desirable as a guide 
to the new user, and to stimulate activity toward a "most optimum" 
network usage. 
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(cont) 


g) Prospective Customer Briefing Requirements 

The prospective network member is briefed in a rather informal 
manner. During the initial briefing at ARPA he is briefed on the 
network in general and on the one time and yearly recurring costs, 
is advised of other sources of information such as BBN, MITRE, NIC, 
etc. He is then directed to one of the network facilitators for 
further indoctrination and assistance in procuring the necessary 
Host services and the required software. Commitments and obliga¬ 
tions of the prospective customer are determined by ARPA, and 
other than general obligations for provisions of access, account¬ 
ability, etc., no formal commitments are sought from the prospective 
member. Presently the new member must do a fair amount of in¬ 
vestigation to determine hardware interface, costs, and availability. 
The methods for briefing the new customer are rather informal and 
consists of limited use of blackboards, drawings and some 
reference material. In general it takes much too long and involves 
many meetings with the facilitators and others to become an active 
network user. 

RECOMMENDATIONS 

A single organization should be tasked with the responsibility of 
assisting a new user to become an active network member. Formal 
briefings should be prepared that are all inclusive and directed 
to both the technical and executive levels of the new member 
organizations. Up to date and uncomplicated material should be 
prepared to expedite the new members proficiency in using the 
network. Hand holding should be a continuing thing for a period 
of up to two weeks with the new user at his facility. Following 
this period, active follow up action on the part of the hand holding 
group should be a periodic requirement until the new user is pro¬ 
ficient in use of the network. 
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h) Advanced Planning Recommendations 

ARPA presently does all planning of future developmental effort. 

BBN is tasked for the actual development of the hardware. This 
arrangement, judging from results, is more than adequate. As more 
reliance is placed on the network, new developments must be in¬ 
corporated into the network in a manner causing the least inter¬ 
ruption to satisfactory service. 

Priorities for developmental tasks are established by ARPA in such 
a manner as to provide an orderly time sequence of events. 

Statistics on the growth in traffic volume, and the number and 
types of users could be obtained. A statistics gathering and re¬ 
porting method permitting growth projections, and categorization 
of users, has not been established. The "healthy net" concept 
should be more clearly defined. 

Systems level planning is accomplished in a manner that provides 
for technological advances. The HSMIMP is cited as an example. 

The impact of new development is assessed in terms of higher 
traffic volume, and cost effectiveness. The dual logistics, pro¬ 
gramming, software promulgation, and other operational aspects 
must be evaluated before a true impact can be determined. 

A considerable amount of data is gathered by BBN and NMC. However, 
this data is not made available in a form readily usable to establish 
present or projected requirements. 

Due to the R&D nature of the on going development, cost effectiveness 
is evaluated in conjunction with what is determined to be the best 
technical approach. Cost effectiveness will increase in importance 
as modifications are made to the network. A cost analysis pro¬ 
cedure should be implemented as an aid in evaluating future de¬ 
velopment . 

The implementation of the network will be established by ARPA 
requirements. There are indications that a more detailed implementa¬ 
tion plan would provide better coordination between the agencies 
involved. In the case of the HSMIMP an implementation plan 
identifying all action agencies, and a detailed test plan to de¬ 
termine capability and operational readiness prior to network 
commitment appears highly desirable. 
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4/h (cont) 

RECOMMENDATIONS 

It is recommended that a single agency be assigned the responsibility 
of gathering and assembling cost and operational statistics necessary 
for an advanced planning effort, and to perform an implementation 
planning function that will provide fully detailed plans, with 
action agencies assigned, and to coordinate the implementation of 
these plans. This type of planning and assignment of responsibilities 
should insure the least possible interruption of network services. 
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5 ) Network Operations Requirements Study 

a) Inter-Company Coordination Arrangements. 

The inter-company coordination arrangements maintained by ARPA in its 
contractor contacts has been rather informal and conducted in a "can 
do" atmosphere. This has resulted in remarkable accomplishments in 
creating and expanding the ARPANET to its present form. It has been 
ARPA policy to find a reliable, conscientious group; contract with 
that group to perform a particular job and then with a minimum of 
direction permit them to accomplish the work. This attitude has 
permeated the coordination arrangements of their contractors and 
subcontractors. 

The BBN negotiations with Honeywell resulted in delegating the main¬ 
tenance responsibility completely to Honeywell. This has included 
responsibility for the spare parts, installation effort, and even 
some of the retrofits. In nearly all instances the maintenance 
effort* provided by this arrangement has been satisfactory. 

There has been very little planning or scheduling of contractor support 
activity other than the BBN-Honeywell scheduling of preventive main¬ 
tenance. The measurements conducted by NMC are in most cases not 
coordinated with the rest of the network. 


The network has evolved in a cooperative atmosphere and most requests 
for network support are satisfied in this way. 


Initial contacts with AT&T for new installations are informal with 
the result that lead times are held to a minimum. An easy informal 
relationship has developed between BBN and AT&T so that the check¬ 
out and maintenance is accomplished with a minimum of network dis¬ 
ruption. It has resulted in a great deal of benefit to the carriers 
in their quality and reliability efforts on wide band facilities. 

The character of the ARPANET is changing almost as fast as it is 
expanding. More and more voices are heard asking for help in the 
costing and accounting area, guidance to system programmers to keep 
them from burdening other hosts in the net with trivia, guidance on 
goals, help in acquiring resource documentation and many other aspects 
of the network. 


RECOMMENDATIONS 

A beginning must be made to formalize somewhat the inter-company 
coordination arrangements. Within the BBN-Honeywell maintenance re¬ 
lationship a formal requirement for reports of corrective maintenance 
is needed; formal scheduling of retrofit installations would ensure 
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that all machines are retorfitted at about the same time; a more 
formal logistics control is desirable. The measurements conducted 
by NMC should be formally scheduled through the operational control 
center of the net, particularly if there is a possibility of the 
measurement disturbing network operation. 

The need within the network community for an established single point 
of contact which is able to appropriately respond to requests for 
support or service is rapidly accelerating and may be critical in the 
near future. 

The formal requirement to provide up-to-the-minute information to 
NIC to maintain the network directory should be levied on every Host 
organization. 


35 



J 


nately this has not been fully the case in the procurement of services 
for the network, but this is not surprising in view of the rapid net¬ 
work expansion. 

Complete retention of procurement authority by ARPA has somewhat 
inhibited application of cost and reliability effectiveness criteria 
_J particularly in software- and service areas. 
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RECOMMENDATIONS 

The.establishment of published policies for the procurement of documen¬ 
tation of resources and network services is considered essential for 
continuing stable network expansion. 

It would be highly desirable to have cost analysis and reliability 
analysis studies performed to provide criteria for procurement de¬ 
cisions. The data for these recommended studies should be embodied 
raMTq? 1110(311163 of the proposed Automated Management Information System 
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5 ) (cont) 


e) Reporting Requirements 

All ARPA contracts require' the periodic submission of management/ 
administrative reports and .technical status/progress reports. These 
reports are of a narrative type, some of which are automated in the 
sense of being filed on-line on a computer rather than in a hard 
copy format. The Quarterly Technical Reports issued by BBN are one 
example of the required reports. The BBN-NCC Monthly Statistical 
Summary reports are not formally required, but have developed as a 
result of ARPA-BBN interaction and as a by-product of monitoring of 
the network by the NCC. 

There are no requirements for reporting operational status, main¬ 
tenance or logistic activities, reliability, quality nor cost 
statistics. 

RECOMMENDATIONS 

Requirements to provide reports can only be justified by the needs of 
management for the tool the report provides. It is recommended that 
an automated management information system (AMIS) be developed and 
implemented to provide the report tools needed by management for 
planning the development of the network. 

A logical approach to the AMIS design is that of building block 
modules, in which the first modules to be developed and implemented 
are those that collect and store data which is currently available 
within the network. One of the most crucial modules for the utility 
of the AMIS is the report output module. This should be a query 
responsive program which can address and retrieve data from one or 
several of the modular data banks, and compare, summarize, or operate 
on the data in response to the original query. It should have the 
capability to accept a query for a report tool that is needed on a 
periodic basis, and store the query so that the response is auto¬ 
matic output with the periodicity requested. Another feature of this 
module should provide for the security that is deemed necessary by 
management. This security feature would allow upper management to 
access all of the data bank modules with no restriction on their 
queries, but the quality control analyst would be restricted in queries 
he could pose to the AMIS. Wide latitude should be provided in the 
output formats which may be elicited by the query. 

The module which addresses data necessary for cost analysis should 
embody a complete mechanism for automatic cost accounting and-billing 
for network use, even though it is inactive at this stage of ARPANET 
development. 
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The data collected by the NMC in the course of their studies should be 
address e d as a module of the AMIS. The data collected by MIT on the 

th^AMIS Y S ° n the network should form another module of 


The complete range of management-tools provided by reports on main- 

examined and whe're''necess^, "pro'v^e^^moSule^and tT^ 

collect the regurred data and mahe it available to appropriate users. 


The dynamic expansion 
in the design criteria 


of the ARPANET should be a prime consideration 
for the development of all the AMIS modules. 
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f) Inter-Agency Coordination 


The coordination between DECCO and ARPA for the acquisition of wide 
band facilities has been adequate for a tremendous network growth. 

This is not so true for the NMC and NIC efforts. It is quite possible 
that a more aggressive attitude to what was desired from the NMC would 
have produced a continuing coherent system of network measurements 
for network understanding rather than isolated reports. A more 
specific policy on the obligations of network members as to supplying 
documentation of their resources and points of contact within their 
organization would undoubtedly have enabled the NIC to io a much more 
creditable job with their assigned task. 

There is a need for more specific policy in the area of responsibility 
of network agencies to avoid duplication of effort. An example of 
this is in the NMC responsibility, where BBN doesn't consult with 
NMC but simply makes their own system measurements for their under¬ 
standing of the network and its interaction with the IMPSYS software. 
While this has been practical during the embryonic stage of ARPANET 
development, it is clearly apparent that it will result in excessive 
overhead traffic which will be unbearable as the net matures. This 
is true of the measurements made by other Hosts such as MIT and of 
the excessive use of the ECHO protocol by certain systems. All of the 
use of these measurement schemes should be controlled and policy 
should dictate that a controlling agency for measurement be established. 

Specific statements on the obligations of each network member with 
regard to the documentation of resources and updates thereto, and to 
supplying directory information would allow the NIC to provide much 
more useful functional documentation. It is also suggested that a 
customer service be instituted to aid the network member in pro¬ 
viding this documentation in the format for inclusion in the NIC 
functional documents. 

RECOMMENDATIONS 

It is recommended that a single organization be responsible for 
actively documenting existing and future nodes and for providing this 
documentation to the NIC for inclusion in the functional documents. 

The full cooperation of each node is essential to this effort. In 
addition this organization should be responsible for assisting new 
customers in the use of the functional documents and of the ARPANET 
to realize the full potential of the nets capabilities. 

In the area of network measurements it is recommended that a single 
point control agency be established to coordinate and control all 
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g) System Expansion 

There has been no effort by ARPA to solicit prospective network 
users, but their procedures for the investigation, approval, and 
integration of new users have been quite adequate for tremendous 
expansion that has occurred since-1969. 

The only effort to determine the network self-sufficiency threshold 
was a study for Educom by the Wharton School of Business, however 
their report was not available. 

ARPA's goal is to put out an RFP within the next 18 months to get 
someone to run the subnetwork commercially as a carrier. Technically 
the ARPANET is nearing a threshold where resources and services are 
available, reliable and accessible to the extent that a person can 
reasonably come in, choose his tools and swing them around to do 
his will. But from a management point of view much remains to be 
done to reach a comparable threshold. 

There are no indications that network management will in any way 
restrict network expansion. The economic factors which limit ex¬ 
pansion are the paucity of wide band facilities and the long lead 
time to acquire them. If network expansion reaches an undetermined 
point at which it is necessary to use some kind of an area code 
routing scheme, the expansion would be halted for want of some very 
high speed exotic hardware. If the HSMIMP development has been 
completed, it may very well be the hardware needed to handle the 
central point switching function. 

Plans are well along for extension of the network via satellite 
beyond the continental limits, but expansion by interconnection 
with other networks such as MERIT or TSS will not take place. 

Plans for higher bandwidth communication channels and message 
processors with higher throughput are well underway with a HSMIMP 
development program at BBN and an experimental 230 kbps link in use 
at Ames. 

RECOMMENDATIONS 

The planning efforts by ARPA have admirably provided for the future 
system expansion and we have no recommended changes. 
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h) Policy As To New Customers 

The sole arbiter over prospective members is ARPA and the criteria for 
that decision, but not necessarily in order of importance, are first 
a comparison of the network cost with their alternatives, second the 
propriety of their membership in -the ARPANET and last their use of 
the net must in some way further the R&D goals of DOD and the network 
development. 

There is no formally established set of policies governing the new 
' customers obligations to the network nor the ARPANET guarantees to 
the customer. The new user is reguired by the joining agreement to 
treat the ARPANET hardware properly and allow access to that hardware 
for maintenance purposes. A certain amount of pressure is exerted 
by ARPA on all network users to conform to established protocols, 
and on service Hosts to maintain reliable and efficient service and 
provide an administration as convenient for the user as possible, 
however none of this is guaranteed. The new member is obligated to 
provide his own special Host/IMP interface and NCP software. The 
ARPANET offers continuous communication service on the net but makes 
no guarantee to that effect. 

No effort is made to solicit new members for the ARPANET at this time. 
RECOMMENDATIONS 

The network development toward a more operational configuration dictates 
the need for a more formal set of policy statements for the guidance 
of new customers. These policy statements should address separately 
the obligations of the three classes of new customers. The user class 
is probably the simplest with their obligation limited to proper care 
of and access to the network hardware, the server class should have 
these same obligations, plus the requirements to supply complete user 
oriented documentation on the resources offered and to provide some 
consulting service to the user and to provide current directory in¬ 
formation. One further obligation should be that once a resource is 
offered to network users, it may not be withdrawn from service until 
network management approves the action. The obligations of the inter¬ 
active research centers would be much the same as user nodes plus the 
obligation to explore with network management the usefulness of special 
resources developed in their research efforts and when requested make 
a resource available to the network users on their own or some other 
machine. 
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(cont) 


i) Equipment Control/inventory Techniques 

BBN maintains property control records of all major units of network 
hardware and their location, and an annual inventory is conducted 
with a report, thru ACO channels. These property control records are 
not automated and it would not presently be feasible to attempt an 
automated equipment/configuration control system using this data 
base. 

BBN uses government property control forms to maintain their records 
and they also maintain a file of signed receipts which acknowledge 
delivery of network hardware at the installation site. 

BBNs accountability system includes major hardware units but the 
system does not attempt to account for parts or expendable items. 

The BBN property custodian is responsible for all network hardware, 
and he assures that each major unit has a government property tag 
affixed and that it is entered in his property control record. 

RECOMMENDATIONS 

It is recommended that an automated equipment/inventory control 
system be implemented as soon as possible. This activity is so 
intimately a part of the complete cost analysis and cost account¬ 
ability as to be a necessary adjunct to it. The system should 
address accountability for parts and controlled expendables. 
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g) Network Status Reporting 

The network contractor has developed admirable statistics gathering 
routines and a very thorough status and statistics reporting mech¬ 
anism within the IMP operating program. The periodically reported 
status and statistics data is used at the Network Control Center for 
monitoring the health of the communications subnetwork as well as 
for providing summarized reports to ARPA covering Host traffic 
statistics and network availability figures. The reported data 
and other statistical data gathered by the IMP program are further 
applied to technical analysis for evaluating the effectiveness of 
the IMPSYS algorithms as well as measuring parameters to foster 
insight into the character of distributed networks. The only 
criticism of this area might be that the analysis effort is usually 
conducted only in response to identified problems as opposed to a 
sustained analysis endeavor. In general the scope and quality of 
the available statistics on the communications subnetwork leave 
little to be desired but the use and application of the statistics 
could be improved. 

Statistics on Host responsiveness and availability are routinely 
collected by the Network Measurements Center and other interested 
Hosts. Little use is made of these statistics at present, but 
they will eventually become an important user and management tool 
in measuring server merit and capabilities. As yet little effort 
has been directed toward further measurement of server characteristics 
.in the form of resource availability statistics. 

RECOMMENDATIONS 

No changes are recommended to the present subnetwork status re¬ 
porting techniques. It might be beneficial to direct more attention 
to the statistics on Hosts’ availability, and response over periodic 
time frames, as the information looses its discrete identity 
through summarizing. 
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3) (cont) 

h) Quality Control and Analysis 

No requirement has been levied on the network contractor or any 
other organization to maintain an overall quality analysis effort. 
ARPA has generally retained the entire responsibility for evaluating 
the quality of all effort involved in developing and operating the 
network. This evaluation has been essentially restricted to 
measuring accomplishments against goals due to the limited size of 
ARPA resources and the lack of an organized management information 
system. 

No problems have been identified due to the present approach, 
however it is readily apparent that more detailed analysis of the 
network performance will become necessary as the network community 
grows and changes in character. Cost and technical analysis of 
the services provided to the customer will eventually dominate those 
figures as they apply to optimizing the communications subnetwork. 

RECOMMENDATIONS 

An organized management information system should be established to 
readily provide, in a presentable manner and timely medium, the 
data required for analysis and decision making in the areas of cost, 
technical, and reliability analysis. The management information 
system should further provide on-line historical and scheduling 
information relative to on-going tasks and advanced planning. 

It is also recommended that resources be directed toward sustained 
reliability and cost analysis programs that will aid and reinforce 
the decisions that shape the character, purpose, and direction of 
the network. 
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4) (cont) 


a) Hardware Development 

Hardware development is accomplished by BBN as a result of require¬ 
ments established by ARPA. The development to date consists of the 
hardware and software for the IMP, and the TIP. On going work 
covers the Satellite IMP and the--HSMIMP (high speed modular IMP). 

The Satellite IMP is being designed to work with satellite trans¬ 
mission circuits, and is dictated primarily by the longer circuit 
delays. Operation of these units with Hawaii, and Oslo is anticipated 
during the first half of 1973. 

The HSMIMP is being developed to provide a data throughput of 1.5 
megacycles. This unit is being developed to handle traffic densities 
anticipated when the ILLIAC IV at Ames becomes operational, and to 
permit the network to be segmented by area. Operation of the 
HSMIMP is anticipated late in 1973. 

BBN also has responsibility for the Network Control Center. While 
the NCC does gather operational data, it is not being used for 
any extensive performance analysis type work. 

RECOMMENDATIONS 

In view of the goal of eventual transfer of the network to a 
commercial organization it is recommended that an agency be assigned 
the responsibility of gathering and assessing data as necessary for 
a systems analysis effort. This effort should identify and define 
the network parameters, identify the areas where optimization is 
feasible, and the relative significance of each of these areas. 
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4 ) Network Analysis, Development and Planning 
b) Software Development 

The software for the net has been as dynamic as the net itself which 
is typical of a "state-of-the-art" research project. It has now 
evolved into an operating system which is performing its defined 
function. How well it is performing this function has not been 
measured, in effect the very dynamics of the system have hampered 
the measurement effort. To date, software simulations have not been 
used as a tool for measurement and hence, revised or validated 
system design. For example, the simulation of different routing, 
queuing, and buffering algorithms, buffer sizes, traffic patterns, 
traffic volume, etc., using data currently being collected by BBN 
could be used as an effective system design and certification tool. 


The checking out of software modifications prior to their implementa¬ 
tion on the net has not been highly successful. A contributing 
factor to this is the fact that the modifications must be checked 
out on the BBN computer and whatever equipment happens to be in 
transit to a new user. Another contributing factor is the lack of 
documentation and certification of the software prior to its im¬ 
plementation on the net. As more users come on the net and more 
users become dependent on the net to get their job done, more con¬ 
trol must be put on changes in the net to assure that the users can 
rely on the net as a service. 


The issues of Host protocols, and NCP development have been handled 
by working groups and individual Hosts, which.has led to the lag in 
the development in this area. It would be advantageous to im¬ 
plement s central point of control and support for this very 

important task. 


RECOMMENDATIONS 


These recommendations are made, not as a criticism of how the net 
has advanced to its currenj: status, but rather with the realization 
that the goal is to transform the net from its current R&D status 
to a "commercially" viable service. 


1. Implement documentation and certification procedures for net¬ 
work software. 

2. Implement procedures, and capability to more thoroughly check¬ 
out software modifications. 

3. Establish a system analysis function, perhaps independent of 
the software developer, to develop statistical and simulation 



21 



3/f (cont) 
recommendations 


It is recommended that an integrating force be initiated that could 
establish and enforce clear (but not necessarily stringent) guide¬ 
lines for the documentation, guarantees and procedures required in 
locating and using resources available to the network community. 

It is further recommended that a more extensive and aggressive 
program of documentating network resources be undertaken to improve 

the NIC role. 
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3) (cont) 


f) Coordination Between Various Users and Communications 
Systems 

Coordination of services required to maintain the communications 
subnetwork is performed by BBN who also arbitrates any disputes 
concerning these services. Disputes that cannot be resolved by 
BBN are referenced to ARPA, whose decision is final. 

There is no coordination and relatively few guidelines governing 
interaction and transactions among members of the network community. 
This approach has shortcomings which are expressed by a lack of 
cooperation, coordination, and sense of direction among its diverse 
membership. This can, in part, be attributed to the fact that the 
network community is strongly oriented toward specific areas of 
individual research and are only peripherally supportive of the 
network as a communications entity. The dominating group in this 
respect would be research dedicated sites that, though they may 
have Hosts, they are not interested in marketing excess capacity 
over the network (if indeed they have any). Network connection 
affords them the advantages of communicating information and sharing 
central files and processes within subgroups sharing mutual interests. 

An ad hoc market place is established on the network by member 
categories of servers and users. The service sites which provide 
computer facilities for remote usage receive the benefit of using 
the network as a means for marketing excess capacity. Complement¬ 
ing the service sites are users, who for all intents and purposes 
have no computing power at their local sites, but interconnect to 
the network through a TIP in order to utilize the available services 
connected to the network. Matching these members to achieve high 
levels of utilization and concomitant operating economies is 
hampered by the lack of a central brokerage agency to provide the 
means by which interested users and service Hosts could be brought 
together. The documentation (Resources Notebook) containing in¬ 
formation on computing capacity,available at each Host and the types 
and cost of services provided, as well as the means of establishing 
accounts and accessing the services is generally inadequate at 
present. 

This leads to agreements being made directly between the computing 
centers and the users in an ad hoc fashion, with the user learning 
of available resources through personal contact and associations. 

This approach can tend to encourage use of local installations 
(time sharing systems) which are easier to deal with (accounts, 
guarantees, etc.) and find out about due to their proximity. ■ 
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3 ) 


(cont) 


e) Software Certification 

The software development practices of the network contractor is one 
of the few areas where there is almost universal criticism expressed 
by the network community. Although the network members recognize the 
necessity for continued development and sympathize with the problems 
presented with debugging a program of this complexity they become 
uniformly upset when the network is inoperable for extended periods 
of time while malfunctioning network software releases are being 
debugged on-line by BBN. It cannot reasonably be expected that 
major revisions to IMPSYS can be completely debugged prior to re¬ 
lease into the network, but it should be expected that software re¬ 
visions would be meticulously verified and reasonably checked out 
to minimize errors prior to release into the operating system. The 
problem can be expected to become even more acute due to the growing 
size of the network community and the requirements for extensive 
revisions to IMPSYS dictated by conceptual developments, expansion 
beyond national boundaries, and adapting to advanced communications/ 
mediums (i.e. broadcast satellites). / 

REC OMMENDATIONS 

Resources should be directed toward establishing an effective 
verification/certification program for IMPSYS development. The 
effort should be directed toward reducing the deleterious impact of 
revised IMPSYS releases on the operating network without imposing \ 
unnecessary restrictions that would be nonconducive to responsive I 
and resourceful software development by the network contractor. I 

Clearly, one requirement would be to establish a test cell with the \ 
capabilities to more closely approximate a distributed network en- \ 
vironment with traffic simulation and other variable parameters that' 
would be established through network analysis. The modeling of the 
test cell, once refined, will allow development of sophisticated 
simulation and verification techniques that should yield a high 
degree of confidence in revisions without ever imposing any re¬ 
strictions on the developers of IMPSYS. Once the revision is 
verified and released into the network there should be organized 
simulations and measurements performed by, or in conjunction with, 
the Network Measurements Center to further verify the new IMPSYS 
version. 
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3) (cont) 


d) Hardware Installation and Modification 

From an operations standpoint the date, location and configuration 
of new node installations are of primary interest. Using this in¬ 
formation the NCC can establish initial contacts and some famili¬ 
arity with the applicable long lines controllers and Honeywell 
field maintenance personnel concerned with servicing the new node. 
Additionally they will prepare to insert IMPSYS revisions recognizing 
the new node and Host(s), as well as updating their NCC monitoring 
software and other NCC network monitoring peripheral tools (topology 
displays, IMP configuration records, etc.). 

As the installation date approaches they will review and adjust 
scheduling of activity within the topology related to the new node 
to minimize the deleterious effects of a prolonged outage during 
the new node installation. 

During the pre-installation period the NIC will establish the new 
node within their distribution system by initially providing them 
with the basic network functional documents and other appropriate 
information. At the same time the NIC will begin to solicit, 
assemble, and distribute information related to the new Host's 
characteristics. Due to their passive role in soliciting infor¬ 
mation the NIC may be unable to produce any information of valne 
on the new Host until well 1 after he is established on the network. 

With respect to modifications, the control center schedules their 
performance and must be cognizant of their application as it effects 
diagnostics or the operating program within the individual imps. 

RECOMMENDATIONS 

The only recommendation in this area would be to raise the metabolism 
of the information collection effort performed by the network in¬ 
formation center as it is not sufficiently productive at this time. 
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c) Planning and Scheduling 

The planning and scheduling functions as pertains to operations, 
are performed by BBN in a reasonable and effective manner. The low 
level of utilization of network capacity during the development 
stage has deferred any stringent-requirement for evaluating or 
analyzing the scheduling functions impact on capacity, response, etc. 
As traffic volume increases some form of systems analysis may be 
required to maintain an effective scheduling mechanism. 

RECOMMENDATIONS 

Consideration should be given to applying network measurements as 
an analytical tool to optimize the scheduling of element outages. 

In the same vein, a point will probably be reached whereby large 
scale network measurements, simulations, and modeling exercises by 
responsible or interested network researchers may have a deleterious 
effect on regular traffic throughput. Here again, a knowledge of 
network capacity would assist the network control center in scheduling 
tests of this nature so as not to affect the average user. 
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3 /b (cont) 

RECOMMENDATIONS 

The establishment of a sustained maintenance analysis effort would 
be beneficial with respect to cost effectiveness and, indirectly, 
customer satisfaction. The program should be oriented toward de¬ 
termining the levels and degree of maintenance required for a dis¬ 
tributed network with a heterogeneous membership dispersed over a 
broad geographic area. Additionally, an analysis program would 
provide a means to measure the performance and effectiveness of the 
contracted maintenance effort. 
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3) (cont) 


b) Maintenance (Hardware/Software) 

BBN has the responsibility for maintaining IMP to IMP communications 
service within the communications subnetwork. In performing this 
function they have retained responsibility for the IMP operating 
software and have contracted for—IMP maintenance service from Honeywell 
Corporation. They further ensure service by coordinating response 
from the carrier, who has responsibility for modem to modem main¬ 
tenance of the communications channels. 

The degree of rapport between these groups with respect to restore 
activity is exceptional with relatively none of the finger pointing 
problems that are so common when independent elements are melded 
into one function. It is generally recognized that this environment 
is largely due to the proficiency of the network control center in 
correctly diagnosing problems and producing relatively few false 
alarms. 

The effectiveness of the preventive maintenance effort is difficult 
to measure as very little maintenance or reliability analysis takes 
place under the existing contract. The reliability figures pro¬ 
vided by BBN indicate the failure rate of the IMP to be nearly four 
times as frequent as the rate Honeywell predicts for the basic. 316 
computer. It is possible that the large discrepancy between these 
figures is due to the interpretation of what constitutes a failure, 
however it does raise the question of whether some maintenance 
analysis might not be desirable. 

Although the network is of a continuous operational nature the present 
Honeywell maintenance contract covers repair response during prime 
time periods only, with additional cost for seldom requested "brown 
time” effort. The extent that the two situations might be incom¬ 
patible could not be measured during the study. However it is 
reasonable to assume that prime time service in a continuous oper¬ 
ations environment is not an optimum situation. The service node 
that is partitioned from the network may not feel the effects of 
the partitioning but his network users will. Further, an inoperable 
IMP being held for prime time maintenance at an inactive location 
is affecting overall network capacity and is a potential hazard to 
partitioning his active neighbors in conjunction with other IMP 
failures. In general, as the network encompasses an ever increasing 
time zone spread the distinction between prime time and brown time 
becomes meaningless to the members of a distributed network. The 
researcher in Honolulu views prime time on his resource at MIT or 
the University of London in a far different manner from the main¬ 
tenance representative in Massachusetts or London. 
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3)a (cont) 


RECOMMENDATIONS 

As the network community expands and traffic increases thru increased 
participants and knowledge more attention should be devoted toward 
increasing network availability by further improving the diagnostic 
tools available to the NCC to in-sure prompt restore action on all 
failures. Attention must also be directed toward ensuring that the 
network control center is continuously capable of monitoring and 
servicing all elements of the network regardless of the effects of 
NCC equipment failures or partitioning of parts of the network. This 
is becoming increasingly important due to the diversity of the communica 
tions subnetwork operating elements (customized IMPs, HSMIMPs, etc.). 

It is recognized that the NCC generally has adequate back-up monitoring 
equipment available and it is further recommended that some form of 
back-up monitoring and reloading routines be distributed at friendly 
Hosts in a manner that would provide the NCC with the capability to 
activate the routine and receive the necessary information for ser¬ 
vicing parts of the network that might become inaccessible via the; 
network due to partitioning. 

A formal scheduling system should be established at the NCC that would 
ensure the entire network community is aware of the scheduled un¬ 
availability of all nodes. On-line distribution and storage of the 
'schedule on a periodic update basis would be the preferable means of 
ensuring all members are informed on a timely basis. 

Although the problems associated with network user assistance can be 
attributed to the growing pains associated with any original enter¬ 
prise, the de facto market place established by the network must be 
organized to some extent if it is to satisfy users and foster growth. 

An integrating force should be established that is responsive to the 
needs of the entire network community (servers, users, research) and 
also will act as a forcing function in establishing and maintaining 
the documentation and procedures required to bring servers and users 
closer together. 
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3 ) Network Operations Responsibility 
a) Routine Operations 

The responsibility for maihtaining orderly network operations has 
been assumed by BBN. In response to the need for monitoring network 
operations during network development BBN established a network 
control center at their Cambridge' facility. This control center has 
gradually evolved from "as available" coverage to continuous coverage 
in the essential areas of scheduling and monitoring network operations. 

The control center appears highly effective in the area of problem 
identification, diagnosis and restore action. Contributing to this 
effectiveness are very good working relationships with the main¬ 
tenance contractors and utilization of a well designed status re¬ 
porting and diagnostics system. On the other side of the ledger is 
the presently unavoidable, but undesirable, practice of reducing 
availability by deferral of restore activity on complex problems that 
are held for analysis by BBN development personnel. One deficiency, 
of consequence, is the absence of provisions for maintaining un¬ 
impaired network control under partitioning circumstances. If any 
part of the network is partitioned from communications with the net¬ 
work control center* that part of the network must rely on individual 
user recognition and reporting of any subnetwork problems. 

The scheduling of activities (installations, maintenance, etc.) 

affecting communications subnetwork capacity is executed with reason¬ 
able logic and acceptable effectiveness. However, there are apparent 
deficiencies in the coordination details with respect to the accord 
and notification of all involved participants, including interested 
parties. An example is that the entire network community is not 
formally notified of when individual Hosts will be unavailable due 
to scheduled subnetwork outages. This practice can be distressing 
to the network user who is attempting to schedule his activity with 
various Hosts. 

The network user, new and established, is probably the most neglected 
element within the present development atmosphere. The mechanisms 
for assisting and encouraging new members are relatively informal or 
nonexistent in comparison to the services offered by the average local 
time sharing system. Contributing to'this problem is the sluggish 
response of the server Hosts in adjusting their operating philosophies 
and documentation to deal with distant users where assistance cannot 
be provided in face to face contact. Further compounding the problem 
is that the average user's level of knowledge and familiarity with 
the network is dropping as the community expands from the group of 
sophisticated and involved Hosts that were initial network participants. 
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2) (cont) 


coordinates the installation of t;ie circuits, as well as the inter¬ 
faces with other common carriers when necessary. 

Network Measurements Center (NMC) 

'Network Measurements Center, located at UCLA, has a contract to 
perform traffic measurements on~the ARPANET. Using a Sigma 7 com¬ 
puter and a Kleinrock simulation model, they stimulate artificial 
traffic on the net and conduct time, efficiency and congestion 
measurement studies of the network. 

Honeywell, Inc. 

BBN has in their design of*the system hardware specified the 
Honeywell 316 computer as the processor for the network nodes. It 
was therefore logical to subcontract the maintenance responsibility 
to Honeywell as the maintenance organization in the field. Respon¬ 
sibility for calls to Honeywell’s technicians rests with BBN/NCC. 


Lockheed 


BBN has in the development of the HSMIMP specified the Lockheed 
SUE minicomputer as the core building block in their design. -It 
is probable that Lockheed will only serve as a supplier of parts 
for the HSMIMP implementation and deployment. 
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2) (cont) 

on the project. They manage most of the day-to-day operation of 
the netowrk as well as provide the design, fabrication and installa¬ 
tion of the IMPs and TIPs; develop the IMP and TIP software; design and 
fabricate Host interface when requested, or approve design if Host 
customer does their own; maintain hardware (via subcontract with 
Honeywell) as well as' software for IMPs and TIPs; conduct advanced 
research to improve network hardware, and IMP-Host and IMP-IMP proto¬ 
cols; provide and operate the Network Control Center (NCC). The 
NCC performs two major functions: (1) it monitors the communication 

subnetwork (24 hours a day, 7 days per week); diagnoses failures; 
calls on Honeywell or the common carriers, as appropriate, to initiate 
maintenance; debugs and reloads IMPS and TIPs; and (2) summarizes 
and reports network usage, circuits errors and outages, and IMP per¬ 
formance. Network data is derived from status reports received from 
each IMP on the network by the NCC computer. Although the collection 
of data has been automated, the analysis of the data has been manual 
until very recently. The data is now semi-automatically summarized 
monthly for several reports. 

Network Analysis Corporation (NAC) 

NAC has,a contract to design, optimize and recommend to ARPA the 
network configuration (topology) for minimum-cost, given the 
capacity and reliability specified by ARPA. Whenever a new node 
is planned for the network, a new configuration is generated. Based 
on these results, the communication lines may or may not be re¬ 
routed. With ARPA funds, NAC developed a computer program (which 
changes rapidly) to aid in this network topology planning. NAC 
has an average of 4 people working on this project. Along with 
BBN, NAC has a very important role in the planning and engineering 
of the ARPANET. 

Stanford Research Institute (SRI) 


SRI has a contract to operate a Network Information Center (NIC) 
which is based on an on-line computer program to provide on-line 
and hard-copy documentation for network users. Examples of doc¬ 
umentation are announcements of resources available at each Host 
site, network protocols and dissemination of working papers for 
the members of the Network Working Group. 

Defense Commercial Communications Office (DECCO) 

DECCO received orders from ARPA for communication services and 
procures these from common carriers. They deal with AT&T who 
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2) Network Description 

A description of the physical aspects of the ARPANET are readily 
available from the literature, and we will only attempt to describe 
the operational, organizational and functional configuration of the 
existing management structure of the network. 

There are three distinct areas of_management in the ARPANET: 

1) Management of the Host computer systems at each node; 2) Manage¬ 
ment of the daily operations of the communications subnet; and 

3) Management of the future development and expansion of the 
communications subnet. 

The management and administration of the Host computers resides 
with the system owner as most are research facilities, and engaged 
in numerous activities other than network participation. Preser¬ 
vation of this autonomy was of primary consideration in the net¬ 
work design philosophy. 

The network sponsor, ARPA maintains the overall management of the 
network. Various aspects of this management responsibility have 
been delegated through contracts to perform tasks with regard to 
design, fabrication and daily operation of the communications sub¬ 
net. 

The organizational and functional relationships between ARPA and 
other groups in the daily operation of the ARPANET are portrayed 
in figure 1, while ARPA's management of the future development 
of the network is shown in figure 2. 

Advanced Research Projects Agency (ARPA) 

ARPA handles initial contacts with prospective users; treats all 
policy and cost matters; negotiates formal agreements with new 
users; interacts with the NAC, common carriers, and DECCO to order 
new or changed communications services; orders IMPs/TIPs from 
BBN; brings new/prospective users and members of the NFG together; 
monitors activities of the'NWG; generally, functions as the 
central management for the network. 

Bolt Beranek and Newman, Inc. (BBN) 

BBN, on a CPFF contract, is the principal contractor for the 
communication subnetwork. BBN has a group of about 25 people now 
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communications at somewhat less than a fourth of the computing 
costs of the systems connected to the net. 

The insights provided in the above allow us to now return to the 
initial statement of ARPANET community purpose and some of its 
implications, assuming that a transparent communications service 
is available. “ 

Resource availability implies that any program should be able to 
call on the resources of other computers in the community with 
. an ease and reliability and response comparable to calling on one 
of its own subroutines. This concept immediately implies the 
practicability of distributed access to distributed data bases and 
use in data management or data retrieval systems. The impact of 
this on the general data processing community may well engender a 
radical change in philosophy to take advantage of these capabilities. 
For not only can the remote data base be accessed as if it were 
local, but the network user can program his own computer to collect 
data from several locations for comparison, merging and further 
analysis. 

The global concepts involved in our initial statement provide a 
much more powerful and sophisticated tool in allowing the systems 
programmer to call several powerful computers to simultaneously 
work on a single problem. We can now begin to visualize the vast 
potential of the ARPANET community. 

The future becomes very exciting if we consider the network as we 
know it today as only the forerunner of future networks. Most of 
the information carried by the U. S. Mail today is amenable to 
electronic transmission techniques so within twenty years mail may 
be relegated to a minor role while most information will be de¬ 
livered via something quite like the ARPANET. 

In this future, the corporate executive would have a single console 
at his desk, connected into the company computer, which in turn is 
a member of the network community. He would be able to request on 
his console a wide variety of services from exchange quotations to 
his own data management system to a scientific modeling and sim¬ 
ulation service. 
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1 ) Purpose of the Network 

The basic purpose of the ARPANET community is to provide an environ¬ 
ment in which the resources available to one member are equally 
available to other members of the community without degradation or 
regard to location. This basic purpose is so global a concept that 
it deserves considerable amplification, however we will initially 
address the purpose of the ARPANET communication subnetwork. 

The subnetwork has been built to provide a transparent communica¬ 
tions medium for the interconnection of a set of interactive 
heterogeneous computer installations. The implications of this 
simple statement of purpose are not readily apparent, and to under¬ 
stand we must examine the premises of reliability, responsiveness, 
capacity and cost on which it is based. 

Reliability in a computer community is always compared with the 
characteristics of the computer itself. The network design recog¬ 
nized this fact and insured this reliability by providing at least 
two transmission paths between any two nodes, and by giving re¬ 
transmission of messages until received error free. 

Interactive resource sharing requires a communications responsiveness 
within the human short-term memory span, and interactive graphics 
use requires rapid reaction to interrupts plus the ability to dis¬ 
play about 20 kilobits of data within one second. The design 'goal 
to satisfy such stringent response requirements was the ability to 
transmit a 1,000 bits of data in 0.5 seconds between any pair of 
nodes. 


/ The capacity of the communications medium becomes an important con¬ 
sideration when one realizes that with 40 network computers, each 
with its dozens of time shared users, there could be, at peak hours, 
one or more conversations between all 780 pairs of computers. Net¬ 
work capacity is defined as the throughput rate at which satura¬ 
tion or lowered response occurs, and is dependent on carrier band¬ 
width, topology, traffic distribution between pairs of nodes and 
the average message size. The capacity necessary to maintain a 
transparent communications medium was incorporated into the net¬ 
work by the flexibility to add transmission lines as needed. 

Last but not least in the design premises, is that of cost. Prior 
to the implementation of the ARPANET, each computer center was 
forced to recreate all of the software and data files it wished to 
use, which can be very costly. The ARPANET alleviates this problem 
and its value to a user is directly proportional to the number of 
other workers on the net who are creating potentially useful re¬ 
sources. The design goal of the ARPANET was to provide 
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Introduction 


I. 


This report presents the findings, conclusions and recommenda¬ 
tions as a result of an eight week study of the ARPANET covering 
the existing operations, development, and administrative 
functions of the networks communications subsystems. 

The study was undertaken as a result of the networks rapidly 
growing popularity and changing character. While retaining 
some character of a research and development project with 
technological advances still to be implemented and evaluated, 
it is simultaneously and rapidly assuming the character of a 
highly advanced efficient operational resource sharing net¬ 
work within the DOD research community. This changing character 
brings with it a new set of obligations and problems which 
must be recognized and dealt with effectively in order to 
satisfy the goals of the two "half worlds". 

The content of the report is not intended to be critical of 
any individuals or groups efforts as they presently exist, 
but rather to point out areas requiring changes, different 
approaches, and new effort in order to effectively continue 
the R&D effort while satisfying the new operational network 
demands. Another important consideration is the posture and 
character required of the network to be ultimately attractive 
to commercial interests. 

The study consisted of discussions, demonstrations, and observa¬ 
tions at the headquarters and operating sites of all network 
contractors and agencies required to sustain daily operations. 

The following organizations were visited: 

Advanced Research Projects Agency, Arlington, Virginia 
Bolt, Beranek and Newman, Inc., Cambridge, Massachusetts 
Network Analysis Corporation, Glen Cove, New York 
MITRE Corporation, McLean, Virginia 
American Telephone & Telegraph, Washington, D. C. 

Massachusetts Institute of Technology, Cambridge, Massachusetts 
Stanford Research Institute, Menlo Park, California 
Ames Research Center, NASA, Mountain View, California 
Rand Corporation, Santa Monica, California 
University of California at Los Angeles, California 
Univeristy of California at Santa Barbara, California 
Information Sciences Institute, Marina Del Ray, California 

A summary of the findings with appropriate recommendations 
are presented in Section II. 
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